Writing software applications for real world problems such as telephone switching communication protocols is an extremely complex procedure. Such software applications require a large number of hours to create, frequently are delivered with numerous problems, and are difficult to modify and support. The difficulty in creating and supporting large applications is primarily due to the inability of existing software development paradigms to provide a framework for simplifying the software development process. The complexity of the software has been shown to increase as an exponential function of the number of different operations that it is expected to process with current paradigms. A 1000 line program which might require one month to develop may be contrasted with a 2000 line program requiring six months or more of development effort. Large programming efforts have in the past almost beyond the capabilities of development in terms of reasonable performance, reliability, cost of development, and reasonable development cycles.
Object oriented technology (OOT) improves productivity whenever a problem can be simplified by decomposing it into a set of black box objects. Object oriented technology depends upon the benefits of data hiding, inheritance, and polymorphism to simplify a software design. If an application cannot be subdivided into objects, object oriented technology does not offer significant productivity improvements. Object oriented technology also does not address how to design the underlying behavior of an object which must change its behavior as a function of the order in which events come in. The underlying behavior of an object with this type of requirements is best designed using a finite state machine methodology.
The current state/event software strategy is to assign each step in processing a state number. A decision tree or table is used to route an event to a processing route that is specific for the current state and event. Neither a functional or object oriented design strategy reduces the complexity and amount of state/event processing software for the following reasons:
Deeply nested function calls are required to reduce the size of the program. This deep nesting obscures understanding of the operation of the system and further distances the software implementation from a graphical representation, such as a state diagram. PA1 A single event can result in one of many possible state changes. The specific state is often a function of various status and database parameters. If the conditions required to make a specific state transition cannot be graphically specified as is the case with state as number paradigm, understanding of the state machine operations is obscured. PA1 It is difficult to reverse engineer a complex finite state machine (FSM) implementation. The underlying state event relationships is best understood by a software engineer if expressed in a graphical drawing which shows states as bubbles or boxes and the events which result in transactions to new states as arcs between the states. This graphical representation cannot be found in the software implementation due to the fact that the software operations required to implement the state changes are distributed across all of the software. Therefore the initial software implementation must be manually coded from its graphical representation. Existing programs in which initial documentation has either been lost or is obsolete require an extensive process to regenerate the more intuitive graphical representation. PA1 Modifications to software frequently introduce errors because the change failed to stop a timer or release a resource upon exit from a state. The state as number paradigm hides the facilities which are allocated. PA1 Most implementations contain numerous event routines with similar but not quite identical behavior. The number of bugs in a system usually increases with the size of the software. Eliminating redundant code should improve the reliability of a system. PA1 The state design usually results in a flat architecture (vs. hierarchical), which results in a complex design. Hierarchical state machines are natural solutions for some problems such as communication protocols but other problems require keen insight into the problem domain to permit decomposition into two or more hierarchy levels. Flat architecture is difficult to maintain for the following reasons:
The number of interconnections between states is large. PA2 Redundant states with similar behavior interconnect with different states. Complex designs are more error prone than simpler designs. PA2 Automatic generation and testing of the application state machine from a graphical specification is usually not practical due to the random nature of the processing performed and distribution of state changes.
All of the above factors makes it difficult to improve the productivity of the development of complex software. The object oriented paradigm cannot be used by itself to improve the quality and reduce the development cost of complex software state machines. Object oriented technology does not address the inner workings of an object's state/event code. The fundamental difficulty with the software state machine paradigm is that it models a state machine as a collection of state numbers and event routines.